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1 . Type of Application 

This new application is for a(n) 
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□ Design 

□ Plant 
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2. Benefit of Prior U-S. App!ication(s) (35 U.S.C. 119(e) 120, or 121) 

^ The new application being transmitted claims the benefit of prior U.S. 
application(s) and enclosed are ADDED PAGES FOR NEW 
APPLICATION TRANSMITTAL WHERE BENEFIT OF PRIOR U.S. 
APPLICATION(S) CLAIMED. 
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Papers Enclosed That Are Required for Filing Date under 37 CFR 1, 53(b) 
(Regular) or 37 CFR 1.153 (Design) Application 

39 Pages of specification 
6 Pages of claims 

I Pages of Abstract 

I I Sheets of Drawing 
Kl formal 

□ informal 

□ The enclosed drawjng(s) are photograph(s), and there is 
also attached a "PETITION TO ACCEPT PHOTOGRAPH(S) 
AS DRAWING(S)". 37 CFR 1.84(b). 

Additional papers enclosed 

□ Preliminary Amendment 

□ Information Disclosure Statement (37 CFR 1 .98) 

□ Form PTO-1449 

□ Citations 

□ Declaration of Biological Deposit 

O Submission of "Sequence Listing", computer readable copy and/or 
amendment pertaining thereto for biotechnology invention containing 
nucleotide and/or amino acid sequence. 

□ Authorization of Attorn ey(s) to Accept and Follow Instructions from 
Representative 

n Special Comments 

□ Other 

Declaration or oath 

Q Enclosed 
Executed by 

□ inventor(s). 

□ legal representative of inventor(s). 

□ joint inventor or person showing a proprietary interest on behalf of 
inventor who refused to sign or cannot be reached. 

Q This is the petition required by 37 CFR 1 .47 and the 

statement required by 37 CFR 1 .47 is also attached. See 
item 1 3 below for fee. 

^ Not enclosed. 
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□ Application is made by a person autliorized under 37 CFR 1 .41 (c) 
on behalf of all the above named inventor(s). 

□ Showing that the filing is authorized. 

6. Inventorship Statement 

The inventorship for all the claims in this application are: 

□ The same. 

or 

□ Not the same. An explanation, including the ownership of the various 
claims at the time last claimed invention was made, 

□ is submitted 

□ will be submitted. 

7. Language 

^ English 

□ Non-English 

□ The attached translation is a verified translation. 37 CFR 1 .52(d). 
8- Assignment 

□ An assignment of the invention to . • 

□ is attached. A separate □ "COVER SHEET FOR ASSIGNMENT 
(DOCUMENT) ACCOMPANYING NEW PATENT APPLICATION" or 

□ FORM PTO 1595 is also attached. 

lEI will follow. 

9. Certified copy 

Certified copy(ies) of application(s) 



country 


appln. no. 


filed 


country 


appln. no. 


filed 


country 


appln. no. 


filed 



from which priority is claimed 

□ is (are) attached. 

□ will follow. 
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1 0. Fee Calculation (37 CFR 1 .1 6) 



A. M 


Regular application. 






CUIMS AS FILED 


Number Filed 


Number Extra 


Rate 


Basic Fee 
37 CFR 1.16(a) 
$ 690.00 


Total Claims 
(37 CFR 1.16(c) 


21-20= X 


$ 22.00 


22.00 


Independent Claims 
(37 CFR 1.16(b)) 


3-3 = 0 X 


$ 80.00 


00.00 


Multiple dependent 
claims, if any, 
(37 CFR 1.16(d)) 


X 


$ 260.00 


00.00 



□ Amendment canceling extra claims enclosed, 

□ Amendment deleting multiple-dependencies enclosed 

□ Fee for extra claims is not being paid at this time. 



Filing Fee Calculation $ 712,00 

B, □ Design application ($310.00-37 CFR 1.16(f)) 

Filing Fee Calculation $ 

C. □ Plant application ($51 0.00-37 CFR 1 .1 6(g)) 

Filing Fee Calculation $ 

1 1 . Small Entity Statement(s) 

□ Verified Statement(s) that this is a filing by a small entity under 37 
CFR 1 .9 and 1 .27 is (are) attached. 

□ Status as a small entity was claimed in prior application serial no. 
, filed on , from which benefit is 

being claimed for this application under: 

35U.S.C. □ 119(e), 

□ 120, 

□ 121, 

□ 365(c), 

and which status as a small entity is still proper and desired. 

□ A copy of the verified statement in the prior application is 
included. 

Filing Fee Calculation (50% of A, B or 0 above) $ 

12, Request for International-Type Search (37 CFR 1.104(d)) 
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□ Please prepare an international-type search report for this application 
at the time when national exannination on the merits takes place. 



Fee Payment Being Made At This Time 

□ Not enclosed. 

□ No filing fee is to be paid at this time. 
13 Enclosed 



$ 712.00 



13 Basic filing fee _ 

□ Recording assignment ($40.00; 37 CFR 1 .21 (h)) (See 
attached "COVER SHEET FOR ASSIGNMENT 
ACCOMPANYING NEW APPLICATION".) $ 00 00 

□ Petition fee for filing by other than all the inventors 
or person on behalf of the inventor where inventor 
refused to or cannot be reached. ($130.00, 

37 CFR 1.47 and .17(h)) $ 

□ For processing an application with a specification in a 
non-English language. ($130.00; 37 CFR 1 .52(d) 

and1.17(k). $ 

□ Processing and retention fee 

($130.00; 37 CFR 1.153(d) and 1.21 (i) $ 

□ Fee for international-type search report 

($40.00; 37 CFR 1.21(e)) $ 



712.00 



Total fees enclosed 



Method of Payment of Fees 

□ Check in the amount of $ . 

13 Charge Deposit Account No. 18-0013 in the amount of $ 712.00 . 
A duplicate of this transmittal is attached. 
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1 5. Authorization to Charge Additional Fees 

13 The Commissioner is hereby authorized to charge the following 
additional fees by this paper and during the entire pendency of this 
application to Deposit Account No. 18-0013 

K 37 CFR 1 .16(a), (f) or (g) (filing fees) 

^ 37 CFR 1.16(b), (c) and (d) (presentation of extra claims) 

^ 37 CFR 1.16(e) (surcharge for filing the basic filing fee and/or 
declaration on a date later than the filing date of the application) 

^ 37 CFR 1 .17 (application processing fees) 

□ 37 CFR 1.18 (issue fee at or before mailing of Notice of 
Allowance, pursuant to 37 CFR 1 .31 1 (b)) 



1 6, Instructions as to Overpayment 



^ Credit Deposit Account No 
□ Refund 

Date: February 14, 2000 

Reg. No. 38,278 
Telephone No. (248) 594-0624 




/John W. Rees 
Rader, Fishman & Grauer PLLC 
1533 North Woodward Ave. 
Suite 140 

Bloomfield Hills, Ml 48304 



□ 



Incorporation by reference of added pages 

^ Plus added pages for New Application Transmittal where benefit of 
prior U.S. application(s) claimed 

Number of pages added _5 
Q Plus Added Pages for Papers Referred to in item 4 above 

Number of pages added 

□ Plus "Assignment Cover Letter Accompanying New Application" 

Number of pages added 

Statement Where No Further Pages Added 

□ This transmittal ends with this page. 
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PATENT 



ADDED PAGES FOR APPLICATION TRANSMITTAL WHERE BENEFIT OF 
PRIOR U.S, APPLICATION(S) CLAIMED 

NOTE: See 37 CKR. § L78. 
17, Relate Back 

WARNING: If an application claims the benefit of the filing date of an earlier filed application under 35 US C 120, 121 or 365{ch the 20- 
year term of that application will be based upon the filing date of the earliest U.S. application that the application makes 
reference to wider 35 use. 120, 121 or 365(c) (35 US C 154(a)(2) does not take into account Jor the determination of the 
patent term, any application on which priority is claimed under 35 US.C 119, 365(a) or 365(b).) For a c-i-p application, 
applicant should review whether any claim in the patent that will issue is supported by an earlier application and, if not, the 
applicant should consider canceling the reference to the earlier filed application. The tenn of a patent is not based on a 
claim-by-claim approach See Notice of April 14, 1995, 60 Fed. Reg. 20, 195, at 20,205 

(complete the following, if applicable) 
13 Amend the specification by inserting, before the first line, the following sentence: 

A, 35U-S.C119(e) 

NOTE- "Any nonprovisional application claiming the benefit of one or more prior filed copending provisional applications must contain or 
be amended to contain in the first sentence of the specification following the title a reference to each such prior provisional 
application, identifying it as a provisional application, and including the provisional application number (consisting of series code 
and serial number). " 37 CF.R. § 1.78(a)(4). 

13 "This application claims the benefit of U.S. Provisional Application(s) No(s).: 
APPLICATION NO(S)-: FILING DATE 

60/166,042 November 17, 1999 

B. 35 U.S.C. 120, 121 and 365(c) 

NOTE: "Except for a continued prosecution application filed under § L53(d), any nonprovisional application claiming the benefit of one 
or more pnor filed copending nonprovisional applications or international applications designating the United States of America 
must contain or be amended to contain in the first sentence of the specification following the title a reference to each such prior 
application, identifying it by application number (consisting of the series code and serial number) or international applicauon 
number and international filing date and indicating the relationship of the applications. . . . Cross-references to other related 
applications may be made when appropriate. " (See § 1.14(a)) 37 CF.R. § 1 78(a)(2). 
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^ "This application is a 

□ continuation 

continuation-in-part 

I I divisional 
of copending application(s) 

^ application number 09/441,289 filed on November 16, 1999. 

□ International Application filed on and which designated the U.S." 

NOTE. The proper reference to a prior filed PCT application that entered the U.S. national phase is the U S. serial number and the filing 
date of the PCT application that designated the U.S. 

NOTE (1) Where the application being transmitted adds subject tnatter to the International Application, then the filing can be as a 
continuation-in-part or (2 ) if it is desired to do so for other reasons then the filing can be as a continuation. 

NOTE- The deadline for entering the national phase in the U.S. for an international application was clarified in the Notice of April 28, 
1987 (1079 O.G. 32 to 46) as follows: 

"The Patent and Trademark Office considers the International application to be pending until the 22nd month from the priority 
date if the United States has been designated and no Demand for International Preliminary Examination has been filed prior to the 
expiration of the 19th month from the priority date and until the 32nd month fi-om the priority date if a Demand for International 
Preliminary Examination which elected the UnUed States of America has been filed pnor to the expiration of the 19th month from 
the priority date, provided that a copy of the international application has been communicated to the Patent and Trademark Office 
within the 20 or 30 month period respectively. If a copy of the international application has not been communicated to the Patent 
and Trademark Office within the 20 or 30 month period respectively, the international application becomes abandoned as to the 
United States 20 or 30 months fi-om the priority date respectively. These periods have been placed in the rules as paragraph (h) of§ 
L494 and paragraph (i) of § 1.495. A continuing application under 35 U.S.C 365(c) and 120 may be filed anytime during the 
pendency of the international application. " 

n "The nonprovisional application designated above, namely application 

, filed , claims the benefit of U.S. Provisional Application(s) No(s).: 

APPLICATION NO(S).: FILING DATE 



□ Where more than one reference is made above please combine all references into one sentence. 
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18. Relate Back— 35 U.S,C. 119 Priority Claim for Prior Application 

The prior U.S. application(s), including any prior International Application designating the U.S., 
identified above in item 17B, in turn itself claim(s) foreign priority(ies) as follows: 



Country Appln. no. Filed 

The certified copy(ies) has (have) 

□ been filed on , in prior application , which was filed on . 

□ is (are) attached. 

WARNING: The certified copy of the priority application that may have been communicated to the PTO by the International Bureau may 
not be relied on without any need to file a certified copy of the priority application in the continuing application. This is so 
because the certified copy of the priority application communicated by the International Bureau is placed in a folder and is 
not assigned a U.S. serial number unless the national stage is entered Such folders are disposed of if the national stage is not 
entered Therefore, such certified copies may not be available if needed later in the prosecution of a continuing application. 
An alternative would be to physically remove the priority documents fi-om the folders and transfer them to the continuing 
application. The resources required to request transfer, retrieve the folders, make suUable record notations, transfer the 
certified copies, enter and make a record of such copies in the Continuing Application are substantial Accordingly, the 
priority documents in folders of international applications that have not entered the national stage may not be relied on. 
Notice of April 28, 1987 {1079 O.G. 32 to 46). 

19. Maintenance of Copendency of Prior Application 

NOTE: The PTO finds it usefiil if a copy of the petition filed in the prior application extending the term for response is filed with the papers 
constituting the filing of the continuation application Notice of November 5, 1985 (J060 O.G 27). 

A. □ Extension of time in prior application 

(This item must be completed and the papers filed in the prior application, if the period set in the 

prior application has run.) 

□ A petition, fee and response extends the term in the pending prior application until 

□ A copy of the petition filed in prior application is attached. 

B. □ Conditional Petition for Extension of Time in Prior Application 

(complete this item, if previous item not applicable) 

□ A conditional petition for extension of time is being filed in the pending prior apphcation. 

□ A copy of the conditional petition filed in the prior apphcation is attached. 
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20. Further Inventorship Statement Where Benefit of Prior Application(s) Claimed 

(complete applicable item (a), (b) and/or (c) below) 

(a) □ This application discloses and claims only subject matter disclosed in the prior application 
whose particulars are set out above and the inventor(s) in this application are 



□ the 



same. 



□ less than those named in the prior application. It is requested that the following inventor(s) 
identified for the prior apphcation be deleted: 



(type name(s) ofinventor(s) to be deleted) 

(b) □ This application discloses and claims additional disclosure by amendment and a new 

declaration or oath is being filed. With respect to the prior application, the inventor(s) in 
this application are 

n the same. 

□ the following additional inventor(s) have been added: 

(type name(s) ofinventor(s) to be deleted) 

(c) □ The inventorship for all the claims in this application are 

n the same. 

□ not the same. An explanation, including the ownership of the various claims at the time the 

last claimed invention was made 

I I is submitted. 

I I will be submitted. 

21. Abandonment of Prior Application ( if applicable) 

□ Please abandon the prior apphcation at a time while the prior application is pending, or when 
the petition for extension of time or to revive in that application is granted, and when this 
application is granted a filing date, so as to make this application copending with said prior 
application. 

NOTE: According to the Notice of May 13, 1983 (103, TMOG 6-7), the filing of a continuation or continuation^in- part application is a 
proper response with respect to a petition for extension of time or a petition to revive and should include the express abandonment 
of the pnor application conditioned upon the granting of the petition and the granting of a filing date to the continuing application. 
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22. Petition for Suspension of Prosecution for the Time Necessary to File an Amendment 



WARNING: "The claims of a new application may be finally rejected in the first Office action in those situations where (I) the new 
application is a continuing application of, or a substitute for, an earlier application, and (2) all the claifns of the new 
application (a) are drawn to the same invention claimed in the earlier application, and (b) would have been properly finally 
rejected on the grounds of art of record in the next Office action if they had been entered in the earlier application. " MPEP, § 
706.07(bl6thed,rev.2n 

NOTE: Where it is possible that the claims on file will give rise to a first action final for this continuation application and for some reason 
an amendment cannot be filed promptly (e.g , experimental data is being gathered) it may be desirable to file a petition for 
suspension of prosecution for the time necessary, 

(check the next item, if applicable) 

□ There is provided herewith a Petition To Suspend Prosecution for the Time Necessary to File 

An Amendment (New Application Filed Concurrently) 

23. Small Entity (37 CFR § 1.28(a)) 

□ Applicant has estabUshed small entity status by the filing of a statement in parent application 

on . 

□ A copy of the statement previously filed is included. 
WARNING: See 37 CFR § L28{a). 

24. NOTIFICATION IN PARENT APPLICATION OF THIS FILING 

^ A notification of the filing of this 

(check one of the following) 

I I continuation 

IXI continuation-in-part 

I I divisional 

is being filed in the parent application, from which this apphcation claims priority under 35 U.S.C. § 
120. 
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65,678-0011 (DCCIE 5298) 

SYSTEM AND METHOD FOR VIRTUAL RENTAL FLEET 

RELATED APPLICATIONS 

This application claims the benefit of U.S. Application 
Serial No. 09/441,289 filed November 16, 1999, and U.S. 
Provisional Application Serial No. 60/166,042 filed November 17, 
1999, both hereby incorporated by reference. 

Background of the Invention 

1. Technical Field s 

The present invention relates generally to an electronic 
system and method for use in the field of asset management and 
electronic commerce, 

2 . Description of the Related Art . 

The field of industrial equipment, such as forklifts, 
includes business entities at several different levels, including 
manufacturers, dealers, third-party financiers, and end-user 
customers. In one common arrangement, the dealer maintains an 
inventory of a wide variety of equipment types for rental to its 
end-user customers (i.e., the dealer's '"rental fleet"). Some 
types of equipment in the dealer's rental fleet, however, are only 
infrequently needed by the dealer's end-user customers. 
Accordingly, such seldomly used items experience a reduced 
utilization rate compared to other items in the rental fleet. The 
dealer tolerates reduced utilization on the seldomly used items 
for a number of reasons, including maintaining customer 
satisfaction, and, hopefully, not giving the customer a reason to 
''shop around" for a new dealer who may have larger inventory of 
seldomly used pieces of equipment. Conventional methods of 
conducting business, particularly providing rental fleets, have 
obvious shortcomings, inasmuch as the full economic value of some 
items in the dealer's rental fleet cannot be realized. 
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Another coinmon business arrangement involves a third-party 
financing company that buys pieces of industrial equipment from 
the manufacturer and then leases the equipment to the end-user 
customer. The customer then utilizes the industrial equipment 
5 (the customer's ''fleet") in its business. In some circumstance, 
the customer actively "manages" the fleet of industrial 
equipment, attending to repair and maintenance, the acquisition 
of replacement equipment, and the retirement of old or 
unproductive equipment from the fleet. In other circumstances, 

10 however, the leasing company performs the asset management 
function. In either set of circumstances, challenges to be 
overcome by fleet managers include how to effectively and 
efficiently determine the timing, selection, and acquisition of 
replacement equipment, and the disposal of equipment being 

15 retired from the fleet or coming to an end of the lease term. 

Known approaches to deal with the foregoing challenges fall 
mostly into the use of manual methods. For example, determining 
whether to replace a poorly performing piece of equipment has 
typically been based on limited data relating to the equipment 

2 0 known by an experienced fleet manager. 

Another approach known for asset management pertains to 
passenger vehicle fleets and involves a computer-based, Internet- 
enabled vehicle selector program. The vehicle selector program 
provides average values for a plurality of different operating 
25 parameters and vehicle types that may be of interest to a fleet 
manager considering vehicle replacement. These parameters may 
include average monthly maintenance cost, and average miles per 
gallon. While the vehicle selector program provides at least 
some useful financial and performance information to the fleet 

3 0 manager, such a system fails to address the ultimate question 

fleet managers encounter: How does a change (i.e., an addition, 
or a subtraction) in the configuration of my fleet effect its 
overall performance? The known vehicle selector program simply 
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does not provide information as to how a combined fleet would 
perform. 

Another challenge, particularly acute for third-party 
financing companies, involves how to effectively and efficiently 
5 dispose of assets whose lease has ended, or will end in the near 
future. Conventional analysis approaches have been haphazard at 
best. They have included utilization of well-known auction 
systems, posting of off -lease equipment on electronic bulletin 
boards and the like for sale purposes, as well as utilization of 

10 consignment networks. One key shortcoming of all these known 

systems of disposing of end-of-lease assets manifests itself in 
the failure to fully realize the full, remaining economic value 
of the asset. One factor contributing to this shortcoming 
involves the lack of information available to potential 

15 purchasers, renters and lessees. Information concerning the 

condition, treatment, and, particularly, the maintenance history 
of the asset during its operating life up to the time the asset 
is being offered for disposal are all important in determining a 
sales price, but are frequently unavailable. In any event, such 

2 0 information is never convenient to obtain. For example, it is 

known in the passenger vehicle fleet industry to make some level 
of maintenance history data on particular vehicle available to 
the potential purchaser. However, to obtain this data, the 
potential purchaser must make a telephonic request to the asset's 

25 fleet manager, who manually looks up the information, and 
provides it (e.g., by way of facsimile) to the potential 
purchaser if it is even available. Obtaining such information, 
therefore, involves a significant investment, both in time and 
effort. The investment is entirely lost if the purchase is not 

30 consummated, and is still partially lost even if the asset is 
finally transferred. The time lag involved in obtaining the 
information also leads to undesirable inefficiency. For example, 
a purchaser may have to make a quick decision regarding whether 
or not to buy a first asset, which would preclude a lengthy 
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investigation of a second asset (e.g., the first asset may be 
sold by the time the investigation of the second asset has been 
completed) . This is particularly inefficient if the second asset 
is a better "fit" for the purchaser than the first asset, 
5 There is therefore a need for a system and method for 

facilitating transactions, and for managing assets of a fleet, 
that minimizes or eliminates one or more of the types problems 
exemplified above. 

Summary of the Invention 

10 In one aspect of the present invention, an electronic 

system is provided for facilitating transactions, particularly 
rental transactions. The electronic system provides, in-effect, 
a ^^virtual" rental fleet available to a user of the system, such 
as a dealer. The system includes an asset configuration unit, a 

15 market database, a market search module, and a communications 
interface. 

The configuration unit is responsive to input data provided 
by a first user of the system for generating a profile of an 
asset. The asset profile comprises asset specification data and 

2 0 a bid definition. In a preferred embodiment the bid definition 
outlines parameters associated with a rental transaction of the 
asset. The market database is configured to store a plurality of 
asset profiles. The market search module is configured to search 
the market database, based on search parameters specified by a 

25 second user, and generate an identification of assets. The bid 
module is configured to allow the second user to select one of 
the assets on which to bid. The bid module is also adapted to 
provide rental options to the second user, based on the bid 
definition for the asset. Finally, the communications interface 

30 is configured for facilitating the electronic remote access by 
the second user of the system. 

Through the foregoing, a dealer or the like is provided 
access to a "virtual" rental fleet of assets, some of which are 
not owned or controlled by the dealer. The system allows a user. 
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such as a dealer, to satisfy the requirements of the dealer's 
end-user customer without having to maintain infrequently used 
items in the dealer's own rental fleet (which experience low 
utilization rates and thus return on investment,) Additionally, 
5 the electronic system also allows a user, such as a dealer, who 
has its own under-utilized assets to consign such assets for 
rental by third parties, thereby allowing an increased, effective 
utilization rate. 

In another aspect of the present invention, an electronic 
10 system is provided for facilitating transactions, including, for 
example, assets disposal. The system, according to this aspect 
of the present invention, provides detailed information 
concerning an asset including the maintenance history data so 
that the user, a potential purchaser, rentee or lessee, may 
15 evaluate the asset. The system includes a first database, a 
market search module, and a communications interface. 

In a preferred embodiment, the first database is configured 
to store information associated with a plurality of assets, such 
as pieces of industrial equipment. The market search module is 

2 0 configured to search the first database, based on search 

parameters specified by the user in anticipation of at least one 
of a purchase, rental and lease transaction. The market search 
module is also adapted to generate an identification of assets in 
accordance with the specified search parameters. At least one of 
25 the identified assets has a description that includes maintenance 
history data of the asset. The communications interface is 
configured to facilitate electronic remote access of the system 
by the user which, in one embodiment, occurs over the Internet. 
The electronic system, according to this aspect of the 

3 0 present invention, maximizes value extraction by making detailed 

information concerning the asset readily available to the user. 
In particular, the maintenance history of the asset constitutes 
information that may increase the price obtained for the asset. 
For example, the maintenance history data is particularly 
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important to a dealer class of users of the system who anticipate 
sub-renting or sub-leasing the asset for a short term, inasmuch 
as a common commercial practice places the responsibility of 
maintenance on the dealer, not the end-user customer. 
Availability of information such as maintenance history data 
electronically, and immediately, substantially minimizes or 
eliminates the cost associated with information acquisition. 

In another aspect of the present invention, an electronic 
system for modeling a simulated fleet is provided. The 
capability to model a simulated or fantasy" fleet of assets 
provides the user with an effective and efficient mechanism to 
perform "what if" analyses. The user can then use the results to 
evaluate what effect proposed changes to an existing fleet would 
have on overall fleet performance. The electronic system for 
modeling a simulated fleet includes a simulated fleet 
configuration unit, a reporting and analysis module, and a 
communications interface . 

The simulated fleet configuration unit is provided for 
allowing a user to add a plurality of assets to the simulated 
fleet. Each asset is defined as having at least one parameter 
associated therewith. For example, in one embodiment, the 
parameter may be a total hourly cost to operate the asset. The 
reporting and analysis module is configured to generate a report 
having a composite output value that corresponds to the 
parameter, and, is characteristic of all of the assets in the 
simulated fleet. For example, the composite output value may be 
a composite total hourly cost for all the assets in the simulated 
fleet. Finally, the communications interface is configured to 
facilitate electronic remote access of the system by the user. 
For example, in a preferred embodiment, the communications 
interface allows access to the system over the Internet. This 
reduces the time and effort to obtain information. The system, 
according to this aspect of the present invention, provides a 
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more effective asset management tool than available using 
conventional systems. 

In a preferred embodiment, some of the assets contained in 
the simulated fleet correspond to assets already contained in the 
5 user's existing fleet. The remainder of the assets in the 

simulated fleet correspond to new or used assets proposed for 
acquisition by the user. The report generated by the reporting 
and analysis module contains a composite output value 
representative of all the assets in a simulated fleet, namely, 

10 both the existing assets, and the proposed assets to be acquired. 
The report may be compared to a second report generated based on 
the performance of the assets in the existing fleet alone. 
Comparison of the two reports by the user allows accurate 
evaluation of the impact of the proposed changes. 

15 Other objects, features, and advantages of the present 

invention will become apparent to one skilled in the art from the 
following detailed description and accompanying drawings 
illustrating features of this invention by way of example, but 
not by way of limitation. 

20 

Brief Description of the Drawings 

Figure 1 is a simplified diagrammatic and block diagram 
view of a fleet management and electronic commerce system in 
accordance with the present invention; 

25 

Figure 2 is a simplified block diagrain view illustrating 
functional modules according to the invention; 



Figure 3 is a simplified diagrammatic view of a screen 
3 0 output of the system of Figure 1, including a link to further 
fleet information; 
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Figure 4 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, showing detailed fleet 
information; 

5 Figure 5 is a simplified flowchart diagram showing the 

steps for a method of adding an asset to a fleets- 
Figure 6 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, illustrating greater detail of 
10 a selected asset, including maintenance history data; 

Figure 7 is a simplified flowchart diagram illustrating the 
steps for a method of consigning an asset for sale, rental or 
lease; 

15 

Figure 8 is a simplified diagrammatic and block diagram 
view showing, in greater detail, the process for generating asset 
specification data and a bid definition; 

2 0 Figure 9 is a simplified diagrammatic view of a screen 

output of a fleet search module of the present invention; 

Figure 10 is a simplified diagrammatic view of a market 
search criteria input form; 

25 

Figure 11 is a simplified diagrammatic view of a screen 
output showing an identification of assets resulting from the 
market search; 

3 0 Figure 12 is a simplified diagrammatic view of a screen 

output showing purchase, lease and rental options; 
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Figure 13 is a simplified diagraimmatic view of a screen 
output showing assets contained in a simulated or fantasy" 
fleet; and 

5 Figure 14 is a simplified diagrammatic view of a screen 

output illustrating a report, including a composite financial 
parameter / for a simulated fleet. 

Detailed Description of the Preferred Embodiments 

10 Referring now to the drawings wherein like reference 

numerals are used to identify identical components in the various 
views. Figure 1 is a simplified diagrammatic and block diagram 
view showing an electronic system 2 0 for managing, tracking and 
conducting electronic commerce, with respect to a plurality of 

15 assets designated 22i, 22n. The assets 22i, 22^ are 

illustrated as being a plurality of pieces of movable industrial 
equipment, such as a plurality of conventional forklifts or 
similar machinery, used in the manufacture of goods in a typical 
factory environment. It should be understood, however, that 

2 0 system 2 0 is configured for operation with a wide variety of 
assets. System 20 is further configured to manage, and 
facilitate commercial transactions involving other assets (i.e., 
those not tracked) that are consigned or otherwise made available 
on an electronic market established by system 20. 

2 5 Before proceeding to a detailed description of system 2 0 

keyed to the drawings, a general overview of the features of the 
present invention will be set forth. 

Electronic system 2 0 overcomes a problem identified in the 
Background, namely, the inability of prior systems to 

3 0 significantly facilitate business transactions that could 

increase utilization of infrequently rented assets in a user's 
rental fleet. Electronic system 20 includes functionality that 
allows users, in-effect, to consign assets on an electronic 
market in a manner that makes detailed information, such as 
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maintenance history, readily available. Through the foregoing, 
users of system 2 0 having under-utilized equipment may use system 
2 0 to ^^post" such equipment on the electronic market for rental, 
lease, or the like by other users of the system. Not only does 
system 2 0 enable some users to increase utilization of under- 
utilized assets, other users, (e.g., dealers) who have an 
occasional need for some equipment (e.g., to provide to their 
end-user customers) , can rent or lease equipment from the market 
in contemplation of sub-rental or sub-lease, without having to 
actually own the equipment. Detailed information, such as 
rnaintenance history data, allow users to make informed decisions. 
Equipment selection efficiency is significantly improved since it 
is commonplace for users such as dealers to be responsible for 
the maintenance of equipment they sub-rent. Well maintained and 
problem free equipment will likely be in the highest demand, and 
draw the highest lease and rental rates . 

Another shortcoming set forth in the Background involves 
the failure to realize an assets' full value upon disposal at the 
end of a lease term. Conventional systems are inefficient and 
inconvenient for making desired information available to new 
owners, leasees, and renters prior to their making decisions 
concerning such transactions . In accordance with the present 
invention, electronic system 20 is configured for facilitating 
transactions by creating an electronic market. In particular, 
system 20 is configured to allow remotely located users to 
electronically search the market based on search parameters they 
specify, and obtain a detailed description of the assets, 
including the maintenance history data. System 2 0 also includes a 
bidding mechanism configured to allow the user to bid on the 
assets. The contemplated transactions can be closed 
electronically. 

As stated in the Background, one shortcoming of 
conventional asset management systems involves the absence of an 
electronic "what if" analysis tool. The present invention 
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overcomes this shortcoming, enabling the creation of a simulated 
("fantasy") fleet. A user of system 2 0 may add a plurality of 
assets to the simulated fleet, including currently held or 
controlled assets in an existing fleet, such as assets 22i, 
22n/ as well as new and/or used assets available in a ^^market" 
portion of system 20. The simulated fleet analysis tool allows 
the user to evaluate proposed changes to an existing fleet. The 
tool may be used to compute parameters of interest that are 
characteristic of all the assets contained in the simulated 
fleet, which can then be compared to the same parameters for the 
user's existing fleet. 

Referring now to Figure 1, system 20 is configured for 
electronic remote access by a plurality of remote users, 
designated 23i, 23^, through remote client computers 24i, 
24n, over a global computer network, such as Internet 26. 
Private networks or dial-up connecting may also be used. 
Inasmuch as system 2 0 performs a variety of functions, such as 
tracking and management of assets, as well as facilitating 
electronic commerce, the users 23i, 23n may fall into a 

plurality of user classes, which are accommodated within system 
20. 

With continued reference to Figure 1, remote client 
computers 24i, 24^ may be any one of a plurality of well known 

computer systems, such as, for example, a personal computer (PC) 
running a Microsoft Windows operating system (e.g., Windows 95, 
Windows 98, Windows NT Workstation, and Windows 2000), or a 
Macintosh computer (Apple Computer) . When used with Internet 26, 
remote client computers 24i 24^ are preferably configured to 

include a conventionally, commercially available web browser, 
such as, for example, Netscape Navigator 4.0 or higher, 
commercially available from Netscape Communications Corporation, 
or Microsoft Internet Explorer 4.0 or higher, commercially 
available from Microsoft Corporation, Redmond, Washington. The 
browser included on client computers 24i, 24^ preferably 
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includes the capability of establishing a secure connection 
through Internet 26, by way of a firewall system 44 with web 
server 30, for example, using a Secure Sockets Layer (SSL) 
protocol described below. Of course, other mechanisms for 
establishing a secure connection, such as the S-HTTP protocol may 
be used so long as both the client computers 24 and web server 3 0 
are configured to include software compliant with the chosen 
protocol. Moreover, the present invention recognizes that 
different client software may be required when using private 
networks or a dial-up connection. 

System 2 0 interfaces with a tracking and management system 
28, and preferably includes a first computer system, such as a 
web server 30, a second computer system, such as an application 
server 32, and a third computer system, such as a database server 
34. One or more of the servers may be combined, depending on the 
size and complexity of system 20, Database server 34 is coupled 
to a market database 3 6 and a global asset database 3 8 comprising 
a fleet database 40 and a preconf igured asset database 42. In 
the client-server architecture described herein, the "server" 
provides the information to the ^^clients". Electronic system 20 
may further include, in an alternative embodiment, a firewall 
system 44 . 

Tracking and management system 28 is configured to 
automatically gather, analyze, and deliver information relating 
to the procurement and utilization of assets 22i, 22n/ so as to 

maximize productivity and to reduce operating cost and 
administrative burdens. Each asset may be provided with a data 
acquisition device for sensing and storing one or more operating 
characteristics associated with the asset. Such information can 
be transmitted to a receiver connected to a collection controller 
contained within system 2 8 for purposes of storing such 
information. System 2 8 may be further configured to 
automatically update individual records associated with each of 
the assets with information received, including for example. 
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maintenance history information, and hour-meter readings. System 
28 is operatively coupled to electronic system 20, particularly 
database server 34, as shown in Figure 1. This coupling allows 
system 2 0 to be updated with current information regarding the 
tracked assets 22i, 22^. Users 23i, 23n may then access and 

review the status of their fleets, over Internet 26, using system 
2 0 as a gateway. Tracking and management system 2 8 may be a 
system as described in co-pending application U.S. Serial No.: 
09/441,289, filed 11/16/99 entitled APPARATUS AND METHOD FOR 
TRACKING AND MANAGING PHYSICAL ASSETS", hereby incorporated by 
reference in its entirety. 

Web server 3 0 operates as a communications interface for 
facilitating electronic remote access of system 20 by users 23i, 

23n via client computers 24i, 2 4^ when using Internet 26. 
Web server 3 0 is preferably compatible with the ubiquitous 
HyperText Transfer Protocol (HTTP 1.1), and includes the 
capability of establishing a secure connection with client 
computers 24i, 24^ via, for example, the publicly available 

Secure Sockets Layer (SSL) protocol. Version 3 . 0 of the SSL 
protocol is commercially available from Netscape Communications 
Corporation. Web server 3 0 may comprise suitable hardware 
configured to handle anticipated traffic (e.g., requests, 
responses) therethrough, and may further execute conventional, 
commercial software, such as Windows NT 4 . 0 operating system 
software running Microsoft Internet Information Server (IIS 4.0) 
software, both commercially available from Microsoft, Redmond, 
Washington USA. 

Application server 32 is configured for running components 
of system 20, described functionally below, as well as serving 
reports. Application server 32 may comprise conventional, 
commercially available hardware, and include conventional, 
commercially available software such as Windows NT 4 . 0 operating 
system software, Microsoft Transaction Server 2,0 transaction 
server software, as well as a conventional, commercially 
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available reporting engine software, such as Power Builder or 
Crystal Reports. 

Database server 34 is configured for executing all database 
serving within electronic system 20, and may comprise suitably 
adapted hardware selected, in part, on anticipated traffic and 
data access response- time standards set for system 20. Database 
server 34 may include conventional, commercially available 
software, such as Windows NT 4 . 0 operating system software, and 
Microsoft SQL server 7.0 database server software, both from 
Microsoft, Redmond, Washington USA. 

Web server 30, application server 32, and database server 
34 define a multi-tiered computing environment configured to 
achieve and implement the functionality to be described in 
greater detail hereinafter. It should be understood that 
alternate architectures may be employed, achieving the same 
functionality, yet remain within the spirit and scope of the 
present invention. 

System 2 0 organizes asset information into several logical 
groups. Market database 36, shown diagrammatically in Figure 1, 
is configured for storing a plurality of asset profiles, 
associated with a corresponding plurality of assets, destined for 
disposal on an electronic market. Contemplated transaction types 
include sale, rental and lease. The asset profile includes two 
parts: asset specification data and a bid definition. The asset 
specification data includes a variety of details about the asset, 
as well as its maintenance history. The bid definition outlines 
the parameters associated with the above-described commercial 
transactions contemplated for the asset. Market database 36 is 
illustrated as a logically separate database, although it should 
be understood that market database 36, in alternative 
embodiments, may be implemented together on the same physical 
hardware as the global asset database 38. Market database 36 is 
configured for rapid retrieval of asset information, as desired 
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to facilitate the electronic coininerce functionality of electronic 
system 2 0 . 

Fleet database 40 is configured to store asset 
specification data for assets contained in fleets being managed 
by system 20. As used herein, "fleet" is a logical grouping or 
association of one or more assets, which may include assets 22i 

22n being tracked and managed by system 28. A ^^fleet" may be 
either (i) a current fleet, or (ii) a simulated or "Fantasy" 
fleet. An existing fleet is a fleet containing assets under the 
control of a user, for example, through ownership or lease. A 
"Fantasy" fleet may contain (i) any assets in any of the user's 
existing fleets ("held assets"), (ii) new or used assets not held 
or controlled by the user such as may be available for purchase, 
rental, or lease from third-parties via the market, or (iii) 
fictional assets having a predetermined usage, and performance 
profile, from the preconf igured asset database 42. 

Preconf igured asset database 42 includes a plurality of 
asset specifications for various asset types. The asset 
specification includes values that may be a composite of a 
plurality of specific, actual assets of the same or similar type. 
For example, a model "A" forklift from a particular manufacturer 
may have an average monthly maintenance cost based on a long 
history of tracking the maintenance cost for model ^^A" forklifts. 
A preconf igured asset brings these composite values when added to 
a fleet. 

Firewall system 44 is disposed between the connecting 
network such as Internet 26, which is generally considered 
"insecure", and the secure, private network on which servers 30, 
32, and 34 reside and execute. Firewall system 44 may be 
implemented in software, hardware, or a combination of both. As 
is known generally, firewall system 44 is configured to intercept 
messages destined for web server 30, or exiting therefrom, and to 
examine such messages, and block those that do not meet security 
criteria. Firewall system 44 enhances the security, and hence 
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the integrity, of the electronic market established by the 
invention. Firewall system 44 may comprise conventional devices 
and methodologies known to those of ordinary skill in the art. 

Figure 2 is a block diagram view of the functional modules 
implemented on electronic system 20. Functional modules include 
a login or authentication module 46, a fleet module 48 comprising 
a simulated fleet module 50 and a current fleet module 52, a 
fleet search module 54, a market module 5 6 comprising a market 
search module 58 and a bid module 60, a reporting and analysis 
module 62, and a bid definition module 64. 

Login 46 provides authentication functions, principally 
through a user ID/password approach. In one embodiment, 
electronic system 2 0 includes several classes of users: a guest 
class, a member class, and a dealer class. A guest is 
characterized as having no member privileges, but can view assets 
available in market database 36, as well as other public areas of 
electronic system 20. A member has an enhanced set of 
privileges. A member may create an actual fleet, and/ or a 
simulated fleet, may conduct searches of the assets contained in 
the members existing and/or simulated fleets, may search market 
database 3 6 and bid on selected assets, run reports and conduct 
analyses, as well as place assets in market database 3 6 for 
disposal. A dealer has access to the features available to 
members, but in addition, has access to a set of dealer tools 
generally unavailable to members, as discussed further below. 
Finally, electronic system 2 0 provides for an administrative 
class of users having heightened, administrative rights and 
privileges, for example to perform maintenance or reconfigure 
system 20. 

Before new users can practically use system 20, they must 
register. Accordingly, associated with login module 46 is a 
registration module (not shown) that allows a new user to 
register, typically as either a member, or a dealer. For 
registration activities and/or user profile changes, web server 
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3 0 and the corresponding client computer 24 communicate via a 
secure, encrypted connection, such as via the SSL encryption 
protocol . 

Regarding existing users, login module 46 is configured to 
automatically log the user in upon detection of an auto-login 
"cookie". A "cookie" is a message that is given to a client 
(e.g., a web browser on a client computer 24i, , 24^) by a 
server (e.g., web server 30). Client computer 24^ will cache the 
cookie, and store the cookie in a file on the client computer 24i 
if the cookie is a so-called "persistent'' cookie. A part of the 
message is a description of the range of URLs (e.g.. 
http://www.ironrhino.com) for which that cookie is valid, and a 
time period for which the cookie will persist. Any future HTTP 
requests by the client computer that fall within that URL range 
(e.g., http://www.ironrhino.com) and valid time period will 
include, with the HTTP request, the current value of the cookie 
to the server. In operation, electronic system 20 is configured 
to query a user 2 3 using a client computer 24 to determine 
whether the user wishes to save the user-login and password. If 
the user responds ''YES" r then electronic system 20, particularly 
web server 30, sends a cookie to the corresponding client 
computer 24, wherein the cookie is stored in a file. When the 
user subsequently accesses the URL from which the home page of 
system 20 are served, the browser portion of client computer 24 
determines a match and will send the auto-login cookie, 
(containing login/password) to electronic system 2 0 for 
authentication purposes. Upon successful login, login module 46 
directs the user (e.g., member or dealer) to the user's start 
page (best shown in Figure 3). 

With continued reference to Figure 2, fleet module 48 is 
configured to allow members and dealers to add their current 
fleet information into electronic system 20 for reporting, 
tracking and analyzing by module 62. It should be understood 
that such activities provide much information regarding the 
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status of the fleet, and upon which important business decisions 
can be based. Simulated fleet module 50 is configured to allow a 
user 23 to access, add, view, edit and delete assets in a 
simulated fleet. According to the invention, the "Fantasy fleet" 
feature allows accurate and immediate "what if" analysis, 
unavailable through the use of conventional systems. Current 
fleet module 52 allows a member or dealer to access, add, view, 
edit, or delete assets in one or more existing/actual fleets 
associated with the registered member or dealer. 

Figure 3 shows a user's "start" page 66 generated by fleet 
module 48 after a successful login. Start page 66 includes a 
navigation pane, a search pane 70, a descriptive text pane 72, an 
advertising/promotions pane 74, an existing fleet information 
pane 76, and a simulated or "fantasy" fleet information pane 78. 

Navigation pane 68 includes, in the illustrated embodiment, 
a plurality of user-invoked (e.g., via ^^clicking" with a mouse or 
other pointing device) functions or operations that enable 
efficient navigation through the various modules of electronic 
system 20. Navigation pane 68 includes a Home button 80, a 
Search button 82, a "My Fleet" button 84, a "Fleet Builder" 
button 86, a STORE button 88, a Library button 90, a Reporting 
button 92, and a FAQ (Frequently Asked Questions) button 94. 
Wherever the user navigates to within system 20, navigation pane 
68 will appear at the top of the screen. 

The "Home" button directs system 2 0 to take the user back 
to an initial login/registration page, which is then displayed on 
the user's client computer 24. Search button 82 invokes fleet 
search module 54, which is configured to search the user's fleets 
to identify assets based on user specified search criteria (e.g., 
make, model, and year of manufacture.) . The "MY FLEET" button 84 
invokes fleet module 48, taking the user to the user's start page 
66, The "FLEET BUILDER" button 86 invokes a fleet builder wizard 
to lead the user through the steps of creating a new fleet of 
actual assets, or a simulated fleet. The "STORE" button 88 
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invokes market module 56, providing the user with access to 
conduct searches of market database 3 6 to identify assets for 
purchase, rental or lease. Library button 9 0 invokes a library 
module (not shown) that allows the user to visit the on-line 
library of system 2 0 for access to downloadable docioinents . 
Reporting button 92 invokes reporting and analysis module 62 for 
obtaining reports containing analysis results for fleet assets or 
market items. FAQ button 94 invokes FAQ module (not shown), 
allowing the user to access questions and answers of interest to 
the users of system 20. 

Search pane 70 includes pull down menus for defining search 
parameters for conducting a search of either market database 36, 
or fleet database 40. The search is invoked, in an illustrated 
embodiment, by selecting (i.e., ^^clicking") on a ^^Search'^ button 
96, 

The descriptive text pane 72 is configured to display 
predetermined text to the user, based on user interaction with 
electronic system 20. For example, descriptive text pane 72 may 
include information instructing the user as to the organization 
of start page 66, and the available options, such as creating an 
actual fleet or a fantasy fleet. 

Advertising/promotions pane 74 is configured to display 
advertising or promotions that may be available. For example, 
certain pieces of equipment may be on a "'lease special", more 
details of which may be found in the site "STORE" (i.e., via 
'^clicking" on '"STORE" button 88 on the user's start page) . 

Current fleet information pane 7 6 comprises the interface 
through which a user interacts with electronic system 2 0 to 
create an actual or a current fleet, and to edit or delete a 
fleet. Fleet information pane 7 6 includes, in the illustrated 
embodiment, a "'Create Fleet" button 98, an Edit button 100, a 
Delete button 102, a radio button 104, and a link 106, Selecting 
(i.e., "clicking") on the "'Create Fleet" button 98 causes fleet 
module 48 to create a new fleet record in fleet database 40, In 
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one embodiment, the record includes a fleet name, and a location. 
Edit button 100, when selected by the user, invokes current fleet 
module 52, which is configured to allow the user to edit the 
fleet name and/or location of the fleet selected by radio button 
5 104. Note that in Figure 3, only one existing fleet (i.e., the 
''Denver Division") is illustrated; however, when two or more 
existing fleets are displayed, each have a corresponding radio 
button 104 associated therewith, and only one of the radio 
buttons may be selected at a time (i.e., is darkened) . The fleet 

10 having a darkened radio button is the "selected" fleet for 

purposes of Edit button 100, and Delete button 102. Selecting 
the delete button 102 causes current fleet module 52 to delete 
the selected fleet from database 40. In the fleet information 
pane 76, in the illustrated embodiment, each existing fleet under 

15 the heading ''Fleet Name" is configured to operate as a link to 
another page generated by system 20, particularly current fleet 
module 52. This "linked'' page provides an identification of the 
assets contained in the fleet. The portion of the "linked" page 
that shows the asset identification is illustrated in Figure 4 

2 0 (portions of the "page" have been omitted for clarity, like the 
Navigation pane 68, which has ^ was already been shown in Figure 
3) . 

With continued reference to Figure 3, Fantasy Fleet 
information pane 78 includes a "Create Fantasy Fleet" button 108, 

2 5 an Edit button 110, a Delete button 112, a radio button 114, and 

a link 116. Pane 78, and buttons 108, 110, 112, 114, and link 
116 operate in a substantially identical fashion to pane 76, 
buttons 98, 100, 102, 104, and link 106, as described above, 
except that they pertain to the Fantasy Fleets, 

3 0 Figure 4 shows a screen output current fleet module 52, 

responsive to a user's selection of link 106 in Figure 3, Figure 
4 includes an identification of the individual assets included in 
the "Denver Division" fleet. In an illustrated embodiment, the 
identification includes a listing of the following parameters for 
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each asset: a serial number, a make, a model, a capacity 
(pounds) , an asset type, an application rating, a usage 
parameter, a utilization parameter (percent) , and a cost/hour 

(U. S . Dollars) . 

The view illustrated in Figure 4 includes an "Add Asset" 
button 118, an "Add Fleet Charge" button 120, an Edit button 122, 
a Delete button 124, a plurality of radio buttons 126, a Move 
button 128, a pull down menu 130 including entries 130i, I3O2. 
130n. and a link 132. The "Add Asset" button 118, when selected 
by the user, causes current fleet module 52 to add assets to the 
selected fleet. This process will be described in greater detail 
below. The "Add Fleet Charge" button 12 0, when selected, causes 
a charge (i.e., monetary charge) to be applied pro-rata to each 
of the assets included in the selected fleet. Edit button 122, 
and Delete button 124, when selected by the user, respectively, 
cause current fleet module 52 to allow the user to edit, or 
delete an asset from the selected fleet. Which asset is affected 
is determined by which radio button 12 6 is selected. The edit 
function allows the user to edit the asset specification data 
associated with the asset. The "Move" button 128, when selected 
by the user, moves an asset (as selected by the radio button 
126), from the current fleet to the fleet chosen by the user from 
one of the entries 130i, I3O2, 130^ in pull down menu which are 

actual fleets as well as to thereby move real, existing assets 
between existing fleets. 

Figure 5 is a simplified flowchart diagram illustrating the 
steps for a method of adding an asset to a fleet. The method 
begins in step 134. The "Add Asset" function may be invoked from 
either simulated fleet module 50 or current fleet module 52, The 
description of Figure 5 will be made with reference to module 52, 
although it should be understood that module 50 could be 
executing the steps as well. 

In step 13 6, current fleet module 52 obtains basic asset 
specification data responsive to input data provided by user 23. 
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While the particular types of information contained in the asset 
specification data will vary depending on the particialar asset 
type involved, in the illustrated eiribodiment where the asset 
comprises an industrial piece of equipment, namely a forklift, 
5 the asset specification data is divided into four subgroups: 
"basic", '"additional", ''usage", and '"performance". In one 
embodiment, the ''basic" asset specification data may include an 
asset type (e.g., a standard forklif t) , a make/model designation, 
a serial number, a year of manufacture, a capacity (e.g., in 

10 pounds), and commentary text. In a constructed embodiment, 
"clicking" the "Add Asset" button causes a dialog box to be 
presented to the user having four tabs labeled "basic", 
"additional", "usage" and "performance". The user moves from tab 
to tab, filling out respective forms, comprising input boxes and 

15 pull down menus. When complete, the user "clicks" on a "SAVE" 
link- The method then proceeds to step 138. 

In step 138, module 52 obtains "additional" asset 
specification data, which in the illustrated embodiment of a 
forklift may include a mast type (e.g., quad, standard, STD, TSU, 

20 etc.), a tire type (e.g., cushion, foam filled, non-marking, 

pneumatic, polyurethane , etc.), a "fuel type", a mast height, a 
tilt selection, an attachment description, an asset description, 
a condition, and an accounting system asset identification (ID) 
number, and a lease ID niimber. As will be described below, 

2 5 reporting and analysis module 62 generates reports that include 

financial parameters, on both a per-asset and a per- fleet basis 
(e.g., average monthly cost) . Part of the cost analysis derives 
from how much is paid monthly to lease or rent the asset. This 
cost information, in one embodiment, is derived from information 

3 0 found in a separate accounting/leasing system (not shown) , and is 

identified and retrieved by electronic system 20 using the 
accounting system asset ID number, and lease ID number, provided 
as "additional" asset specification data in step 138. In an 
alternate embodiment, where the asset being added is not an asset 
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covered under a lease in a leasing system in electronic 
coiranunication with system 20, further financial-option 
information will be obtained from the user for the asset being 
added, which may include a purchase price (including applicable 
5 depreciation information so as to enable calculation of a monthly 
cost amount) , a lease/rental amount, a lease-life rental-term, 
and a residual amount for lease/rent. The method then proceeds 
to step 140. 

In step 140, current fleet module 52 obtains ''usage" asset 
10 specification data, which may comprise the following: an 

acquired-f rom name (i.e., name), an application rating (e.g., 
light, medium, heavy) , a date in service, an active asset 
designation (i.e., yes or no), a number of shifts used, an 
original cost per hour, an original usage, an original 
15 utilization, as well as other features. The method then proceeds 
to step 142. 

In step 142, current fleet module 52 obtains ''performance" 
asset specification data comprising an original hour meter 
reading, a number of warranty months, a number of warranty hours, 
2 0 a date warranted, a date warranty removed, an original equipment 
cost, a list price, a preventative maintenance (PM) hours 
specification, and a burden labor rate. It should be appreciated 
that the original hour meter reading provided to system 2 0 in 
step 142 has a date associated therewith. The meter reading and 

2 5 date form a data pair. Future service events on the asset will 

generally also include further meter readings, such that the 
fleet database will have a plurality of date/meter-reading data 
pairs, each having a different date attached to it, for the life 
of the asset. 

3 0 When the user completes the entry of the asset 

specification data, the user will be prompted to enter 
maintenance history data for the asset being configured. As 
shown in decision block 144, current fleet module 52 determines, 
through a suitable prompt to the user, whether further 



23 



65.678-0011 (DCCIE 5298) 



maintenance history data is available. If the answer is "YES", 
then the method branches to step 146. 

In step 14 6/ current fleet module 52 obtains the next item 
of maintenance history data for the asset being configured. 
5 Maintenance history data may include the job date, a description 
of the problem (e.g., work-related, abuse, breakdown, regular 
maintenance) for which maintenance was required, a diagnosis, a 
commentary, a description of the actual work performed, the name 
of the vendor performing the work (if applicable) , whether the 

10 maintenance source is internal /external , whether covered under 
warranty, a description of the part replaced, a length of 
service, and an hour meter reading (usage) . Financial parameters 
for the maintenance items obtained from the user may include: 
Invoice Number, Invoice Date, Invoice Due Date, Invoice Paid 

15 Date, Total Cost, Labor Rate, Parts Tax, Labor Tax, Labor Hours, 
whether the item is Taxable, Exchange Rate, and Exchange Date. 
Financial parameter values for maintenance items may be used to 
determine total maintenance cost, and average maintenance cost 
for the asset. The method then loops back to decision element 

20 144. If the answer to decision element 144 is '^NC , then the 
method branches to step 148. 

In step 148, the asset specification data, including 
maintenance history data, for the asset being configured is 
stored in fleet database 40. The method then proceeds to step 

25 150, where the ''add asset" portion of the current fleet module 52 
ends - 

The process for adding an asset to a ''Fantasy Fleet", 
although not shown specifically, is the same as outlined above 
for adding an asset to a current fleet, except that fleet module 
30 48 invokes simulated fleet module 50, rather than current fleet 
module 52. 

Figure 6 shows a screen output generated by current fleet 
module 52 for a configured asset. The configured asset comprises 
asset specification data 154 including maintenance history data 
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156. In the example illustrated in the drawing, the user reaches 
the screen of Figure 6 by ''clicking" on link 132 in Figure 4. 
Through the foregoing, a user wishing basic information (i.e., a 
simple identification) of the assets in the user's fleet need 
5 proceed no further than Figure 4. However, for greater detail, 
including a description of the asset, the user can '"drill down" 
by clicking on link 132 to reach Figure 6. Screen output 152 
further illustrates an ''Add Maintenance Item" button 158^ an Edit 
button 160, a Delete button 162, a plurality of radio buttons 164 

10 and links 166, and 167. 

For assets being tracked and managed by way of system 28, 
maintenance history items, such as those illustrated as 
"Preventive Maintenance" and "Steering Mechanism", are 
automatically entered and available to electronic system 2 0 

15 through an information transfer, from a tracking system 28. For 
assets not tracked by system 28, such data is input to system 20 
through "front-end" entry by the user (e.g., selecting the "Add 
Maintenance Item" button 158) , 

The Edit button 160, and the Delete button 162, when 

2 0 selected by the user, cause current fleet module 52 to allow the 

user to either edit, or delete, respectively, the maintenance 
item selected via one of the radio buttons 164. The foregoing 
availability of asset specification data, including maintenance 
history data, enhances real time management of assets in a fleet 
25 (e.g., provides the ability to identify high maintenance items) . 
The user, by selecting or "clicking" on link 166, is 
provided with even greater detail for a selected maintenance 
item, for example, the item captioned "Preventive Maintenance". 
Selecting link 167 causes current fleet module 52 to retrieve an 

3 0 image of the selected asset. Other features may be provided in 

the asset description shown in Figure 6, including links to asset 
specification information provided by the manufacturer, user 
manuals, repair manuals, and many other types of information that 
may be useful concerning the asset. 
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Virtual Rental Fleet 

Referring now to Figure 7, in accordance with the present 
invention, electronic system 20 is configured to facilitate 
5 transactions where a first user, such as a dealer, can consign 
assets, such as forklifts, to the electronic market established 
by system 2 0 for sale, rental, or lease. This feature allows the 
first user, such as the dealer, to increase asset utilization by 
exposure of the asset to a broader audience than just the end- 

10 user customers of that dealer. Additionally^ by making assets 

available that a second user /dealer can rent, with a view towards 
sub-renting to an end-user customer, electronic system 2 0 in- 
effect provides a '^virtual" rental fleet. The rental fleet is 
"virtual'' because electronic system 2 0 enables the second 

15 user/dealer to provide equipment to his end-user customer that he 
does not own. 

Significantly, the availability of maintenance history data 
for an asset allows the second user/dealer to make a better 
informed decision before renting the asset. In the rent /sub-rent 
2 0 scenario this is particularly important since the second 

user /dealer is typically responsible for the ongoing maintenance 
and service of the asset during the sub-rental term (i.e., the 
end^user customer typically does not pickup this responsibility 
during the sub-rental term) . 

2 5 Referring to Figure 7, a method of consigning an asset for 

sale, rental or lease on an electronic market includes several 
steps. These method steps will be described briefly as an 
initial matter, then in greater detail in- turn. 

Step 168 involves generating asset specification data 

3 0 including maintenance history data from input data provided by a 

first user. 

Step 170 involves generating a bid definition from further 
input data from the first user. 
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Step 172 involves storing the asset specification data and 
the bid definition together in an asset profile in market 
database 36. 

Step 174 involves searching, market database 3 6 based on 
5 criteria specified by a second user and displaying the asset 
profile . 

Step 176 involves receiving a selection of an asset from 
the second user for placement of a bid. 

Step 17 8 involves providing, to the second user, one or 
10 more of a purchase, rental or lease options, in accordance with 
the bid definition. Step 178 also includes receiving a bid on 
the asset from the second user, based on the transaction options. 

Step 180 involves receiving an acceptance of the bid from 
the first user. Once the bid has been accepted by the first user 
15 (i.e., the party "posting" the asset on the electronic market), 
bid module 60 operates to close the transaction contemplated by 
the bid. 

Figure 8 provides greater detail of generating step 168 
(producing asset specification data) and generating step 170 

2 0 (producing bid definition) . In particular. Figure 8 graphically 
shows in block form an asset profile 182 comprising asset 
specification data 154, and a bid definition 184. Referring to 
the upper half of Figure 8, asset specification data 154 includes 
a plurality of field values, including maintenance history data 

25 156. Maintenance history data 156, in turn, comprises at least a 
date parameter 186, and an action 188 may be any of the 
information referred to above regarding the maintenance item. In 
the illustrated embodiment, generating the asset specification 
data may be performed by executing the "add asset" method 

30 described and illustrated in connection with Figure 5. 

Bid definition 184 defines the parameters associated with 
the asset being consigned for sale, rental or lease to the 
electronic market created by system 20. The bid definition 184 
defines the bounds of the sale, rental or lease transaction 



27 



65,678-0011 (DCCIE 5298) 

involving the asset. Bid definition module 64 (best shown in 
Figure 2) is configured to generate the bid definition 184 as 
follows. In one embodiment, bid definition module 64, when 
invoked by the user, prompts the user for a bid date 19 0, an 
5 availability date 192, and information defining the classes of 
users allowed to bid on the asset 194. The bid date 190 
establishes the date when the asset is available for other users 
to bid on. The availability date 192 defines the date when the 
asset can be delivered. 

10 Classes of users 194 includes a dealer class 196, and a 

member class 198. With respect to dealer class 196, a logical 
variable 200 is associated therewith, and may take either of the 
values "Y", indicating that dealers are allowed to bid on the 
asset, or ''N" , indicating that the dealers are not allowed to bid 

15 on the asset. As illustrated, logical variable 200 is a ''Y" , 
indicating that dealers may bid on the asset. Likewise, with 
respect to member class 198, a logical variable 202 is provided, 
and may also assume one of the values ''Y" or "N" , In the 
illustrated embodiment, users who are in the member class may 

20 also bid on the asset. It should be understood that other 

logical arrangements, such as the use of a logical "0" or logical 
"'1" could also be used, being an equivalent thereof. 

Bid definition 184 also includes, for each class of users, 
an identification of which of a sale, rental, or lease 

2 5 transaction is available to that class of user. As shown in 

Figure 8, all three of a buy option 204, a lease option 206, and 
a rental option 208 are enabled for both classes of users (e.g., 
members and dealers) . This is shown by a logical variable 210, 
(which are all set to ^^Y") . For each transaction type available 

3 0 to a user class, respective transaction characteristic data is 

obtained from the first user. For example, the transaction 
characteristic data for a sales transaction includes a list sales 
price, such as shown in column 214, and a minimum sales price 
that a second user (e.g., another dealer) must submit to define a 
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valid bid, such as shown in column 212 . The transaction 
characteristic data for a rental transaction includes a list 
rental price for a predetermined period of time (e.g., a month), 
and a minimum rental price for that predetermined period of time 
5 that the second user must submit in order to define a valid bid. 
Finally, the transaction characteristic data for a lease 
transaction includes a total lease amount, and a term. 

In a constructed embodiment, the bid definition module 64 
executes a bid definition wizard. The information obtained from 

10 the first user to populate the fields described above is obtained 
through a step-by-step process, which leads the user along, 
allowing the user to click on checkboxes to select the classes of 
users who will be allowed to bid, as well as what respective 
transactions will be available to that class of user. In 

15 addition, the bid definition wizard, as executed by bid 

definition module 64, allows direct entry of dates, and pricing, 
where appropriate. 

Bid definition module 64 is also configured for storing the 
asset specification data and the bid definition in an asset 

2 0 profile in a market database 3 6 when all the needed bid 

definition information has been collected. This is shown in 
Figure 8 by a double arrowhead line to database 36. 

Having described what bid definition 184 is, and how bid 
definition module 64 operates to obtain such information, a 
25 description of the user's interaction with system 20 will now be 
set forth. To promote the greatest amount of flexibility for the 
user^ electronic system 20 includes an asset configuration unit 
for preparing assets for posting and consignment. The asset 
configuration unit obtains the asset specification data and bid 

3 0 definition to form the asset profile, and comprises multiple 

interfaces /modules . These interfaces/modules include a create 
and define feature of market module 56, a sequence of the add- 
asset feature of fleet module 48 and the add- to-market feature of 
fleet search module 54, and the add-to-market feature of fleet 
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search module 54 (for existing assets and shown in Figure 2) . 
These three approaches will be described in detail in-turn. 

First, in a create and define feature, the asset 
specification data (including maintenance history data) , as well 
5 as the bid definition are made by the first user directly out of 
market module 56. That is, when a first user, such as a dealer, 
wishes to post a piece of equipment on the electronic market, the 
first user, after logging in, initially selects the ^^STORE" 
button 88 (Figure 3) from the user's start page 66, which invokes 

10 market module 56. Market module 56, as one of its available 

functions, would directly allow configuration of an asset (i.e., 
input of asset specification data including maintenance history 
data, as well as the bid definition) . When completed, the asset 
is stored in the market database. 

15 Second, if the user wishes to post an asset on the 

electronic market, but the asset does not presently 
''electrically" exist in one of the user's fleets, then the user 
can follow the ''add asset" process described above in connection 
with Figure 5. Once the asset is created "electrically", the 

20 user then ^'clicks" the ^'Add to Market" button. 

Third, existing assets may be configured for posting as 
follows. A user, for example a dealer, who wishes to post the 
existing' asset in market database 36, would invoke the fleet 
search module 54 by selecting the Search button 82 . found on 

25 start page 66 (Figure 3). Figure 9 illustrates a search form 
that allows the user to search the user's fleets to identify 
assets based on specified search criteria. An identification of 
assets satisfying the criteria is returned by fleet search module 
54. The user then selects the asset to be placed on the market. 

30 As shown in Figure 9, this selection is done by selecting one of 
the radio buttons adjacent the desired asset, and then "clicking" 
the "Add to Market" button 215. Since the asset specification 
data for the selected asset is already stored in the fleet 
database 40, only bid definition 184 need be generated for the 
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asset to prepare it for posting. "'Clicking" on the ''Add to 
Market" button 215 invokes the bid definition wizard, described 
above in connection with Figure 8 . 

Through the foregoing functionality, electronic system 
5 2 0 allows a user, such as a dealer, to consign an asset to an 
electronic market for rental, lease, and/or sale by a second 
user, such as another dealer. This functionality enables the 
first dealer to increase utilization of infrequently used pieces 
of equipment by making those pieces of equipment available to a 

10 larger audience of dealers and end-user customers. In addition, 
the second dealer realizes an increased virtual inventory of 
equipment from which to, preferably, rent (with a view towards 
sub-renting to an end-user customer) . 

In an alternative use of system 20, a non-dealer user of 

15 system 20, for example, an equipment leasing company, may 

purchase infrequently used equipment, for example, and make such 
equipment available through market database 36. The universe of 
dealers (with the dealers sub-renting the equipment to end-user 
customers) and end-users may have a sufficiently high aggregate 

2 0 need for such piece of equipment to justify the purchase and 

ongoing rental to third-parties. In this embodiment, the end- 
user customer need not be aware of the actual ownership of the 
equipment, and will look to the dealer for service, maintenance 
and the like. 

25 

End-of -Lease Disposal 

A particular business type of user who may take particular 
advantage of electronic system 2 0 is one engaged in the business 
of financing the capital requirements of other companies. For 

3 0 example, such financing may involve the lease or rental of 

forklifts 22i, , . , 22n to the company who actually uses the 
forklifts in its business, and who pays a lease or rental fee. 
This type of user often has a large number of leases that may 
represent literally thousands of individual assets that are or 
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will periodically be coming off of lease. Since this type of 
user has no direct use for such assets, such assets must be 
disposed of in an effective manner. The assignee of the present 
invention has determined that the information acquired during the 
5 tracking and management of the asset while the asset was being 
leased can be leveraged into a value proposition when such asset 
comes off of lease and must be disposed of. In particular, the 
assignee of the present invention has determined that keeping 
maintenance history data associated with assets on lease becomes 

10 a value-added feature when disposing of the asset in a fashion to 
be described in detail now. 

Figure 10 shows a market- search parameter input form 216 
generated by market search module 58 configured to allow a search 
of market database 36, Assets that have been tracked and managed 

15 by tracking and management system 2 8 over an operating life (or 
portion thereof) have associated therewith a substantial amount 
of valuable information, including maintenance history data. 
When such assets come off of lease, the particular type of user 
described above (i.e., lessor) transfers these assets into market 

2 0 database 36. Each asset in market database 3 6 has an associated 

asset profile comprising both asset specification data (including 
maintenance history data) and a bid definition. Accordingly, 
since these end-of-lease assets already have the asset 
specification data defined, only a bid definition needs to be 
25 created. Completing the bid definition may be done manually for 
each asset, or may be automated through the use of a 
knowledgebase developed over time. Once the asset profiles for 
the end-of-lease assets are stored in market database 36, then 
the other users of electronic system 2 0 will be able to 

3 0 electronically search the market database, based on search 

parameters they specify, in anticipation of a purchase, rental or 
lease transaction. 

Referring to Figure 10, once such a user invokes market 
search module 58, search parameter input form 216 is displayed. 
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Included in display 216 is a series of radio buttons: a lease 
radio button 218, a buy radio button 22 0, a rent radio button 
222, and an "All" radio button 224. As illustrated, the lease 
radio button 218 has been selected; accordingly, all assets in 
5 market database 36 that are available for lease, and satisfy the 
other search parameters, will be identified and returned in an 
output display, shown in Figure 11 . It should be understood that 
the search results may be further limited based on the other 
search parameters like the class of user conducting the market 

10 search (e.g., whether the user is a "'member^' or "dealer", and 

whether a particular asset has been configured to be bid on by a 
''member" or "^dealer"). Selecting the "All" radio button 224 
results in a search that identifies all assets (i.e., not limited 
to any one transaction type) . Figure 10 also shows that a market 

15 search may be limited by a lower list price 22 6, an upper list 

price 228, as well as a plurality of further parameters, such as 
asset type, make /model, condition, year of manufacture, and 
availability date, as also illustrated. Once the user has 
defined the search, the market search is invoked by "clicking" 

2 0 the Search button 23 0. 

Figure 11 shows a screen output 232 of market search module 
58. Output 232 includes an identification 234 of the assets 
satisfying the search parameters. In the illustrated embodiment, 
identification 234 includes a date available parameter, an asset 

2 5 description parameter, a make and model parameter, a capacity 

parameter, a year of manufacture parameter, a usage rating 
parameter, and a status parameter. The status data in the status 
parameter column, if any, is indicative of whether or not the 
asset has been sold. As shown in Figure 11, status data 2 35 for 

3 0 the "Allegany Mega-8" asset indicates that it has been sold. 

Importantly, each asset, in an illustrated embodiment, is linked 
to a respective description, detailed in nature and which 
includes information beyond that contained in the simple 
identification. A user can "click" on the "Allegany Mega-8" 
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wording that is underlined, and will be hyper-linked to its 
detailed description. Although not shown in Figure 11, the 
detailed description of an asset may be substantially identical 
to the information illustrated in Figure 6. 
5 Screen output 232 further includes a Bid button 23 6, a 

plurality of radio selection buttons 238^ a ^'New Search" button 
240, and an "Add to Fantasy Fleet" button 242 having an 
associated pull down menu 244, Bid module 60 is configured to 
allow the user to select one of the assets identified in the 

10 market search for placement of a bid. To place a bid on an 

asset, the user first selects the asset using the radio buttons 
238. Thereafter, the user '"clicks" on Bid button 236, which 
invokes bid module 60. The Move or Add to fantasy fleet button 
242 will be described in greater detail below in connection with 

15 the simulated fleet feature of the present invention. 

Figure 12 shows a screen output 245 generated by bid module 
60. In a constructed embodiment, output 245 includes the 
detailed description of the asset, similar to Figure 6, but which 
has been omitted from Figure 12 for clarity. Bid module 60 

20 provides transaction options: a purchase transaction option 246, 
a lease transaction option 248, and a rental transaction option 
250. The desired transaction is selected by the user through the 
radio buttons. In the illustrated embodiment, a "Buy'^ 
transaction has been selected by the user. 

25 When the selected transaction is a purchase transaction, 

bid module 60 is configured to prompt the user for a bid price 
offered for the selected asset, which is entered in input box 
252. As used herein, the wording '^prompt" merely means to 
provide a mechanism or means to accept the bid price, and does 

3 0 not suggest or require some active activity, such as a blinking 
input box, input wizard or the like. 

When the selected transaction is a lease transaction, bid 
module 60 is further configured to prompt the user to select a 
lease term, a lease type, and a monthly lease amount offered for 
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the selected asset. As illustrated in exemplary fashion in 
Figure 12, the lease term may be input through a pull down menu 
2 54, the lease type may be input through pull down menu 256, and 
the monthly lease amount may be entered (e,g, , keyboard) in box 
5 258. In a constructed embodiment, the lease term may be one of a 
24 month, 36 month, 48 month, 60 month, and 72 month term. 
Further, in a constructed embodiment, the lease type may be one 
of a category 1, category 2, category 3, fixed- ten (10%) percent, 
fixed- twenty percent (20%) , buyout-new, buyout-used, category 4, 

10 category 5, category 6, and category 7 type leases. Lease types 
may be totally configurable. Of course, other options may be 
used or offered to the user, depending on the asset, market 
conditions, etc. To facilitate the bidding process, bid module 
60 further includes a lease calculator tool which may be invoked 

15 by '"clicking" on the Lease Calculator button 262. The lease 

calculator tool allows the user to specify lease term and lease 
type, and enter a third parameter, either a monthly payment or a 
total lease amount, and have the lease calculator calculate a 
fourth parameter, the other one of the lease amount and monthly 

20 payment. The calculated amount can be directly transferred to 
the monthly lease amount box 258. 

When the selected transaction is a rental transaction, bid 
module 60 is further configured to prompt the user for a monthly 
rental price offered for the selected asset, which may be entered 

25 in box 260. The user may submit the bid by '"clicking" on the 
"Submit Bid" button 264. 

Bid module 60 is further configured to generate a bid 
history (not shown) for each asset that has been posted in market 
database 36. The bid history comprises a listing of each bid 

30 made by the users of system 20 on a particular asset. The bid 
history includes a detail of the submitted bid {e.g., by whom, 
price offered, etc.) . Bid module 60 is also configured to allow 
the user that posts the asset in the market database (e.g., the 
leasing company) , to retrieve the bid history, to review the bids 
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contained in the listing, and finally to accept one of the bids 
to thereby complete the offered transaction. 

Through the foregoing, accumulated information acquired 
from the tracking and managing of assets can be leveraged to 
increase financial return when such assets come off of lease and 
must be disposed of. 



Simulated (''Fantasy'') Fleet 

Conventional asset management systems lack effective tools 
for conducting ^^what if" analyses i.e., modeling a simulated 
fleet containing both actual assets and proposed assets. The 
invention overcomes the shortcomings inherent in conventional 
systems by providing an electronic system 2 0 for modeling a 
simulated fleet. For example, if two older machines, each with 
high maintenance costs, are replaced by two newer machines with 
lower maintenance costs, but with higher lease costs, what effect 
would such a change make on the overall performance of the fleet? 
The Fantasy Fleet simulator of the present invention enables 
computer-based modeling that assists answering such questions. 

As shown in Figure 3, a Fantasy Fleet may be created in the 
same manner as an actual fleet (a fleet with real assets) . A 
fantasy fleet may be created by ^^clicking" on a Create button 
108, which invokes the simulated fleet module 50, which in turn 
prompts the user to input a fantasy fleet name, as well as a 
location. Once the fantasy fleet has been created, assets may 
then be added. 

To promote the greatest amount of flexibility possible, 
electronic system 20, to implement the ^^Fantasy'' fleet feature, 
includes a simulated fleet configuration unit that comprises 
multiple interfaces /modules for setting up and adding assets to 
the fantasy fleet. These interfaces /modules include at least one 
of an add-asset feature of simulated fleet module 50, an add-to 
fleet feature via the fleet search module 54, an add-to-fleet 
feature via market search module 58, and a step-by-step entry 
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system of the fleet builder module (not shown) , accessible via 
the ''Fleet Builder" button on the user's start page 56. Each 
will be described in turn. 

First, the add-asset feature of simulated fleet module 50 
5 may be used. A user may ''click" on link 116 in Figure 3, which 
causes simulated fleet module 50 to generate a screen output 2 66 
--an asset view-- as shown in Figure 13. The user interface 
illustrated in Figure 13 operates in substantially the same 
manner as the user interface illustrated in Figure 4 for assets 

10 contained in an existing fleet. For example, the user, by 

"clicking" on the "Add-Asset" button 2 68, causes simulated fleet 
module 5 0 to present an input data dialog, in accordance with the 
flowchart of Figure 5, for adding an asset. The user then 
configures the asset in the same manner as described above for an 

15 existing fleet . 

Second, the add- to- fleet feature of fleet search module 54 
may be used. As shown in Figure 9, a user can search his fleets 
by selecting search button 82 from the user's start page 66 
(Figure 3) , which invokes fleet search module 54. The search 

2 0 results contain an identification of the assets that are 

available for selection. Selection may occur, for example, 
through the use of radio buttons, as shown in Figure 9. The user 
may then select a destination simulated fleet through the use of 
pull down menu 270, and then add the chosen asset to the desired 

25 fantasy fleet by "clicking" on Add button 272 . 

Third, the add-to- fleet feature of market search module 58 
may be used. The further method for adding assets to a fantasy 
fleet involves conducting a market search, using market search 
module 56, as illustrated in Figure 10. Then, the user adds 

30 assets by selecting the desired destination fantasy fleet through 
pull down menu 244, and "clicking" on the Add button 242. 
Through this approach, items available in market database 3 6 may 
be added to the fantasy fleet. 
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Fourth, a user may use the fleet builder wizard to create a 
fantasy fleet and configure and add assets. The fleet builder 
wizard may be invoked by ^^clicking" on the ^^Fleet Builder'' button 
86 on the user's start page 66. This step-by-step entry system 
leads the user along, prompting for a fleet name, and location, 
an indication that it is a fantasy fleet, and prompts to add an 
asset. The add asset feature of the fleet builder" dialog is 
substantially the same as the ^^add asset" feature of the current 
fleet module 52, described above (e.g.. Figure 5). 

Figure 14 shows a report 274 generated by reporting and 
analysis module 62. In particular, each asset listed in the 
report has an associated plurality of parameters, such as average 
monthly usage hours, total maintenance cost, hourly maintenance 
cost, total lease cost, total operating cost, total hourly cost, 
percent utilization, etc. A user can invoke the reporting and 
analysis module 62 by selecting the Reporting button 92 from the 
"start" page 66 shown in Figure 3. The user may then select the 
target fleet (existing or fantasy) for which the report (s) will 
be generated. A user can evaluate changes made to an existing 
fleet by generating a report for an existing fleet, configuring a 
simulated fleet reflecting the proposed changes, and then 
generating a second report. 

The two reports can be compared and decisions made based on 
the results of the comparison. In the report shown in Figure 14, 
the assets enclosed by dashed-line box 276 are part of an 
existing fleet for which a report (not shown) has already been or 
will be generated by module 62. The assets shown in dashed-line 
box 278 are proposed additions to the existing fleet. The 
combination of the assets in dashed-line box 276, and dashed-line 
box 278 constitute the simulated or fantasy fleet. One exemplary 
parameter is total hourly cost 280. Reporting and analysis 
module 62 is configured to generate report 274 having a composite 
output 282 that is characteristic of all the assets in the 
simulated fleet. The composite total hourly cost 282 can then be 
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compared to the corresponding total hourly cost for the existing 
fleet (in the other report) to make an evaluation of the proposed 
changes. Another composite output shown in Figure 14 is percent 
utilization 284. It should be appreciated that some of the 
composite parameter values are determined by reporting and 
analyzing module 62 according to an arithmetic sum function, such 
as the total maintenance cost parameter. Reporting and analyzing 
module 62 is further configured to determine other composite 
parameters, such as hourly maintenance cost, utilization, and 
total hourly cost, according to an arithmetic average function. 
The parameters dealing with money amounts (e.g., dollars) 
required or desirable to make an asset acquisition determination 
may be characterized as a financial figure of merit. Other 
parameters, such as utilization percent, may be characterized as 
a performance figure of merit. 

To the extent that the specific assets included in the 
simulated fleet have actual usage, performance, utilization, and 
cost data associated therewith, then such information is used by 
reporting and analyzing module 62 in computing composite values. 
However, when the assets are of the type that have no asset- 
specific data associated therewith, then profiled asset 
specification data is used in performing the analysis. 
Additionally, when preconf igured assets from preconf igured 
database 42 are included in a simulated fleet (or in an actual 
fleet) , then composite data for assets of a similar type are used 
by module 62 for analysis purposes. 

In accordance with the provisions of the patent statutes, 
the principle and mode of operation of this invention have been 
explained and illustrated in several preferred embodiments. 
However, it must be understood that this invention may be 
practiced otherwise than as specifically explained and 
illustrated without departing from its spirit and scope. 
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Express Label No. EL 429 912 075 US 



CLAIMS 

What is claimed is: 

1. An electronic system for facilitating transactions 
comprising : 

an asset configuration unit responsive to input data 
provided by a first user for generating a profile of an asset, 
5 said profile comprising asset specification data and a bid 

definition defining parameters associated with one of a purchase, 
rental and lease transaction of said asset; 

a market database for storing a plurality of said 
asset profiles; 

10 a market search module configured to search said 

market database based on search parameters specific by a second 
user and generate an identification of assets according to said 
search parameters, said market search module being configured to 
display to said second user a portion of said asset specification 

15 data for at least one of said identified assets; 

a bid module configured to allow said second user to 
select said one of said identified assets for placement of a bid 
thereon, said bid module being further configured to provide at 
least one of purchase, rental and lease transaction options to 

2 0 said second user in accordance with said bid definition; and 

a communications interface for facilitating electronic 
remote access of said system by said first and second user. 

2. The system of claim 1 wherein said asset specification 
data includes maintenance history data, said market search module 
being further configured to display said maintenance history data 
for said at least one of said identified assets. 
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3 . The system o£ claim 2 wherein said bid definition 
includes a told date defining when said asset will be available 
for placement of a bid thereon, and an availability date defining 
when said asset is expected to become available for delivery. 

4. The system of claim 2 wherein said bid definition 
includes a bidder classification parameter defining classes of 
users allowed to place a bid on said asset. 

5. The system of claim 4 wherein said user classes 
include a dealer class and a member class. 

6. The system of claim 4 wherein said bid definition 
further includes an identification of which of said purchase, 
rental and lease transactions are available to each class of 
users . 

7. The system of claim 6 wherein said bid definition 
further includes, for each transaction identified as being 
available for each class of users, respective transaction 
characteristic data. 

8. The system of claim 7 wherein said transaction 
characteristic data for a rental transaction comprises a list 
price for a predetermined period of time, and a minimixm price 
that said second user must submit to define a valid bid, 

9 , The system of claim 7 wherein said transaction 
characteristic data for a lease transaction comprises a periodic 
lease amount and a lease term. 



41 



65,678-0011 (DCCIE 5298) 



10. The system of claim 2 wherein asset configuration unit 
comprises a fleet module configured to generate and store said 
asset specification data in a fleet database, said configuration 
unit further including a bid definition module configured to 
generate and associate said bid definition with said asset 
specification data to define said asset profile, said bid 
definition module being further configured to store said asset 
profile in said market database. 

11. The system of claim 2 wherein said bid module is 
further configured to generate a bid history for said first user 
including a detail of each bid submitted by said second user. 

12. The system of claim 2 wherein said bid is a first bid, 
said bid module being further configured to allow a third user to 
select said asset for placement of a second bid thereon, said bid 
module being further configured to provide purchase, rental and 
lease transaction options for selection by said third user in 
accordance with said bid definition, said bid module being 
further configured to generate a bid history for said first user 
including a detail of each bid submitted for said asset by said 
second and third users of said system. 

13 . The system of claim 12 wherein said bid module is 
further configured to allow said first user to choose one of said 
bids from said bid history, and to complete said transaction 
offered by said chosen bid. 
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14. An electronic system for establishing a virtual rental 
fleet of assets comprising: 

a fleet module responsive to input data provided by a 
first user for generating asset specification data associated 
with an asset, including maintenance history data; 

a bid definition module responsive to further input 
data provided by said first user configured to generate a bid 
definition defining parameters associated with a rental 
transaction contemplated for said asset, said bid definition 
module being further configured to associate said bid definition 
with said asset specification data to thereby define an asset 
profile that is stored in a market database; 

a market search module configured to search said 
market database based on search parameters specified by a second 
user, said market search module being further configured to 
generate an identification of assets according to said search 
parameters, and display to said second user at least a portion of 
a said asset specification data including said maintenance 
history data for one of said identified assets; 

a bid module configured to allow said second user to 
select one of said identified assets for placement of a bid 
thereon, said bid module being further configured to provide 
rental transaction options to said second user in accordance with 
said bid definition, said bid module being further configured to 
generate a bid history for said first user including a detail of 
said bid; and 

a communications interface for facilitating electronic 
remote access of said system by said second user, 

15. The system of claim 14 wherein said bid module is 
further configured to allow said first user to complete the 
rental transaction contemplated by said bid. 
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16. The system of claim 15 wherein said second user is a 
first dealer registered with said system. 

17. The system of claim 16 wherein said first user is a 
second dealer registered with the system. 

18. A method of consigning an asset on an electronic 
market for rental, comprising the steps of: 

(A) generating asset specification data associated with an 
asset including maintenance history data using input data from a 

5 first user of the electronic market; 

(B) generating a bid definition defining parameters 
associated with a rental transaction of the asset using further 
input data from the first user; 

(C) storing the asset specification data and the bid 
10 definition together in an asset profile in a market database; 

(D) searching the market database based on search 
parameters specified by a second user and displaying to the 
second user at least a portion of the asset specification data 
that includes the maintenance history data; 

15 (E) providing rental options to the second user based on 

the bid definition; and 

(F) receiving, through a global computer network, a bid 
from the second user for a rental transaction. 

19. The method of claim 18 further comprising the step of* 
registering the second user as a dealer. 

20. The method of claim 19 further comprising the step of 
registering the first user as a dealer. 
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21. The method of claim 20 further comprising the steps 

of: 

receiving an acceptance of the bid from the first 

user; and 

5 closing the transaction specified by the bid. 
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ABSTRACT OF THE DISCLOSURS 

A system for managing assets, and facilitating electronic 
coinmerce respecting the assets includes a computerized database for 

5 storing asset profiles for a plurality of assets. The asset 

profiles, each include an asset specification and a bid definition. 
The asset specification includes maintenance history data for the 
asset and the bid definition outlines the bounds for one of sale, 
rental or lease of the asset. Users of the system may search the 

0 database remotely over the Internet for desired assets, and retrieve 
detailed information, such as maintenance history, and then bid on 
the asset for purchase, rental, or lease. Users can also add their 
own assets to the database for search by others. The system also 
includes a fantasy fleet feature for conducting "what if" analyses 

.5 of a simulated fleet containing existing assets and proposed assets. 
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